Description of changes:
max_concurrency previously sized the thread pool only, so branches that suspended (invoke, wait, callbacks) released their thread and the next item started immediately. All items were initiated at once regardless of the configured limit.

Rework the concurrency executor around a single coordinator loop:

• The calling thread owns all branch state and schedules work; worker threads only run branches and report outcomes on a queue. No locks remain in the module.
• max_concurrency now bounds in-flight branches. A suspended branch keeps its slot until it reaches a terminal state, matching the JS and Java SDKs. When every in-flight branch is suspended, the parent suspends with the earliest resume timestamp, or indefinitely.
• Branches start in index order and operation ids derive from the branch index, so scheduling stays deterministic across invocations.
• Timed suspends resume in-process via the event queue timeout, replacing the TimerScheduler background thread.
• Consolidate completion logic (thresholds and reason inference) into CompletionPolicy, replacing ExecutionCounters and the duplicated logic in BatchResult.
• Stop scheduling when a branch is orphaned: an ancestor completed, so all further checkpoints under it would be rejected.
• Record the completion decision in map/parallel summaries and obey it on replay: summaries carry completionReason plus the started-branch index set (startedIndexes, or completedIndexes when smaller), and replay reconstructs the exact live result — same items, same statuses, same reason — instead of re-deriving from child checkpoints. Summaries without the record (checkpoints written by earlier SDK versions, custom summary generators) fall back to checkpoint derivation, preserving old behavior. This also makes FLAT-nesting results reconstructable on replay, which checkpoint derivation cannot discriminate. Handlers now default the summary generator per-field, so user-provided configs get exact replay without opting in.

Behavior changes

• BatchResult omits never-started branches (matching the JS SDK). Previously every item appeared as STARTED even when an early completion meant it never ran; total_count now reflects branches that actually started.
• Configs with only min_successful set no longer fail fast on the first failure. The old tolerance check ignored min_successful when deciding whether criteria existed, so a single failure stopped scheduling; scheduling now continues past failures until min_successful is reached or all items finish, matching the JS and Java SDKs.
• Config bounds are validated at construction, matching the Java SDK: max_concurrency and min_successful must be at least 1, tolerated_failure_count non-negative, tolerated_failure_percentage within 0–100. Previously max_concurrency=0 silently meant unlimited and min_successful=0 silently meant all items.

Testing

• Unit: 1384 tests, typecheck and format clean, examples suite green.
• Cloud conformance (aws-durable-execution-sdk-testing): map 20/20 (including 9-16 MapLargeResult and 9-20 MapOpSerdeReplay, which exercise the summarized-replay path), parallel 22/22 — including 9 previously failing requirements covering max_concurrency semantics and a success_count undercount when min_successful was not reached.

Issue #, if available:
Closes #279

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.